home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980424-19980901 / 000400_news@newsmaster….columbia.edu _Sat Aug 22 17:06:29 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  2KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id RAA14631
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 22 Aug 1998 17:06:25 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id RAA20206
  7.     for kermit.misc@watsun; Sat, 22 Aug 1998 17:06:24 -0400 (EDT)
  8. Path: news.columbia.edu!psinntp!howland.erols.net!newshub.northeast.verio.net!newsserver.jvnc.net!post.servtech.com!hal9000.buf.servtech.com!rchandra
  9. From: rchandra@hal9000.buf.servtech.com ()
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: File Size Limitations?
  12. Date: 22 Aug 1998 15:25:23 GMT
  13. Organization: Verio New York
  14. Lines: 21
  15. Message-ID: <6rmnt3$bau$1@post.servtech.com>
  16. References: <35D1B7CD.597FAF56@sonalysts.com> <6qsu85$dbs$1@apakabar.cc.columbia.edu> <6r488b$kd7$1@post.servtech.com> <6r49b1$3ec$1@apakabar.cc.columbia.edu>
  17. Reply-To: rchandra@letter.com
  18. NNTP-Posting-Host: hal9000.buf.servtech.com
  19. Xref: news.columbia.edu comp.protocols.kermit.misc:9126
  20.  
  21. In article <6r49b1$3ec$1@apakabar.cc.columbia.edu>,
  22. Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
  23. >In article <6r488b$kd7$1@post.servtech.com>,  <rchandra@letter.com> wrote:
  24. >: Do you think maybe the file got chopped in size due to newline
  25. >: conversion?
  26. >:
  27. >Not if it was transferred in binary mode.  If sending from a CRLF system
  28. >(like DOS or Windows) to a NL system (like UNIX, OS-9, or AOS/VS) in text
  29. >mode, the new file will be shorter than the original.  When sending
  30. [...]
  31.  
  32. Yep, Frank, that's basically what I was thinking; one end (likely
  33. receiving) was in text mode, and the other (likely sending) was in
  34. binary mode.  When sending, there were some 13 10 or 10 13 (decimal)
  35. combinations in the file, and the receiving end was dropping out the
  36. 13.  Or it was just summarily dropping all 13's.
  37. -- 
  38. Oooooo-oooo-oooo-ooooo, Oooooo-oooo-oooo-ooooo, Ooooo-weem-oh-wum-ooo-ayyy
  39. In the jungle, the silicon jungle, the process sleeps tonight.
  40. Joe Philipps <rchandra-nospam@letter.com> http://www.servtech.com/~rchandra/
  41. You know what you have to do to send email to me successfully :^)